Skip to content

ci: add PR size labeler with XXL gate#9055

Open
bnusunny wants to merge 8 commits into
developfrom
feat/pr-size-labeler
Open

ci: add PR size labeler with XXL gate#9055
bnusunny wants to merge 8 commits into
developfrom
feat/pr-size-labeler

Conversation

@bnusunny
Copy link
Copy Markdown
Contributor

@bnusunny bnusunny commented Jun 2, 2026

Summary

Adds .github/workflows/pr-size-labeler.yml, a new GitHub Actions workflow that:

  • Labels every PR with one of size/XS, size/S, size/M, size/L, size/XL, size/XXL based on additions + deletions across non-excluded files.
  • Excludes lockfiles, schema/**, snapshots, and image binaries from the count so generated noise doesn't dominate the bucket.
  • Fails the check when the PR is size/XXL (≥ 1,000 changed lines), unless a maintainer applies size/override. Removing the override re-arms the gate.
  • Posts a single sticky comment on XXL PRs explaining the threshold and the override path. No comments for other sizes.
  • Tolerates transient GitHub API errors during sizing/labeling so flakiness never blocks PRs; only the intentional XXL-without-override failure propagates.

Built across six small commits — skeleton → fetch+compute → label management → gate+sticky comment → try/catch → docs.

Action required from a maintainer before this lands

  1. Create the labels. The workflow does not auto-create them. Top-of-file comment in the new file lists the exact gh label create commands; run them in this repo once.
  2. Add Size label to branch protection. The gate only blocks merges if the check is required.

If the labels do not exist, addLabels returns 422; the script's catch swallows it and the gate is silently skipped — so the setup step is load-bearing.

Behavior on each event

Event What runs
opened Compute size, label, post comment + fail if XXL without override.
synchronize Same, on every push. Concurrency group cancels stale runs.
reopened Same.
labeled Recompute and re-evaluate gate (so adding size/override unblocks).
unlabeled Recompute (so removing size/override re-arms the gate).

Test plan

These smokes should be run on a fork before requiring this check in branch protection — pull_request_target runs the workflow file from the base ref, so the workflow needs to be present on a base branch first.

  • Open a fork PR with > 1,000 non-excluded changed lines. Expect size/XXL, sticky comment, failing check. Apply size/override → check passes, comment updates (no second comment). Remove size/override → check fails again.
  • Open a fork PR with ~50 source-line changes. Expect size/M, no comment, passing check. Push another commit that brings the total to ~130. Expect size/M removed and size/L applied.
  • Open a fork PR that adds 2,000 lines to package-lock.json and 5 lines to a .py file. Expect size/XS.
  • actionlint .github/workflows/pr-size-labeler.yml is clean.

@bnusunny bnusunny requested a review from a team as a code owner June 2, 2026 00:13
Comment thread .github/workflows/build.yml
Comment on lines +57 to +75
const EXCLUDE_GLOBS = [
'**/*.lock',
'**/package-lock.json',
'**/poetry.lock',
'**/yarn.lock',
'**/Pipfile.lock',
'**/uv.lock',
'**/requirements*.txt',
'schema/**',
'**/__snapshots__/**',
'**/*.snap',
'**/*.svg',
'**/*.png',
'**/*.jpg',
'**/*.jpeg',
'**/*.gif',
'**/*.ico',
'**/*.pdf',
];
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have any of these except requirements?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A more useful list would be ignore the dep/test/document changes. Could discuss

issue_number: pull_number,
per_page: 100,
});
const existing = comments.find(c => c.body && c.body.startsWith(STICKY_MARKER));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just create a check that success & fail on each commit so we can throw away all these find/update in place logic?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait, this workflow itself is already a check. So we can just fail the workflow if it's more than 1000 useful lines

# gh label create size/XXL --color b60205 --description "PR size: 1000+ changed lines"
# gh label create size/override --color 0e8a16 --description "Maintainer override for size/XXL gate"
#
# Spec: docs/superpowers/specs/2026-06-01-pr-size-labeler-design.md
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-relavant comment

const stale = currentLabels.filter(n => SIZE_LABELS.includes(n) && n !== bucket.label);
const alreadyApplied = currentLabels.includes(bucket.label);

if (!alreadyApplied) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the most useful part is when this feature gates huge PRs. But I don't think we care if its a S or XL. So I'd suggest we just focus on fail/success

uses: actions/github-script@v9
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's use a standalone script.

@roger-zhangg
Copy link
Copy Markdown
Member

Another part is we should update the contribution guild to call this 1000 line limit out & suggestion if they hit this blocker. https://github.com/aws/aws-sam-cli/blob/develop/CONTRIBUTING.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants